home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
UTIL
/
SYS
/
KEYCHANGE
/
!KeyChange
/
ProgInfo
< prev
Wrap
Text File
|
1992-02-09
|
3KB
|
62 lines
Program information for KeyChange
=================================
Most of the module code is fairly standard. Entries are provided for
initialisation, finalisation, service calls (Service_Reset only), and a
single command *KeyChange.
The initialisation code claims workspace and zeroes it. It then
initialises some state flags, and passes the command tail to the code that
deals with the *KeyChange command, to allow the initial mode to be set. All
of this is only done for a real initialisation, i.e. not after *RMTidy.
The rest of the code is executed for any initialisation, and also on a
Service_Reset (as reset releases all claimed vectors). The key state flags
are all cleared to zero (i.e. not pressed), the event vector and buffer
insert vector are claimed, and the key up/down event is enabled. Finally,
the keypad mode is set to reflect the state of the Num Lock key.
The finalisation code disables the key up/down event, and releases the
vectors. On a permanent finalisation the workspace is released.
Despite being rather long, the * command code is very simple. If there are
no parameters the current status is printed out using embedded strings.
Otherwise the parameters are parsed, and result in the setting or clearing
of mode flags. The commands which change the keypad mode also have to deal
with the Num Lock state.
The key up/down code maintains the state of keys in which it's interested,
as it's not clear if the "scan keyboard" OS_Bytes can be called from
interrupt code. The module contains a table with a byte for each possible
keycode; this is either &FF for "not interesting", or a workspace offset in
which to store the state (1=down, 0=up). Further processing is done for the
Shift, Ctrl and Alt keys, to merge the left and right keys into a single
flag (0=neither pressed). The right-hand Ctrl key is treated as either a
Ctrl or an Alt depending on the ctrlon status.
If the padon flag is set, the Num Lock key is also treated specially. This
code deals with the interaction between Num Lock (with Shift or Ctrl) and
the keypad mode. Note that curmode stores the current mode, lastmode the
last Num Lock on mode (1, 3 or 4), and padmode the selected "special" mode
(3 or 4).
Unless mode 2 is being selected, the Num Lock state is forced on. Because
the relevant OS_Bytes aren't re-entrant, this is done with a CallBack.
However, it appears that the keyboard handler also changes the Num Lock
state with a CallBack, and moreover the order in which the two CallBacks are
executed is not always the same. Thus OS_CallAfter is used to interpose a
100 msec delay, which seems to be sufficient.
The heart of the code is the routine called on buffer insertion. It
maintains a flag for characters preceded by a null, as these are top-bit-set
characters and must be passed unchanged. Otherwise, if the character is >=
&80 and the exton flag is non-zero, the code is modified according to the
status of the alt/ctrl keys, and then passed on (see the PRM chapter on
vectors for more details). If the padon flag is non-zero and the keypad mode
is 3 or 4 codes < &80 are checked (using a lookup table for non-numeric
keys) to see if they are keypad keys; this involves looking at the stored
state flags, to distinguish the keys on the keypad from those on the main
keyboard with the same buffer codes. If appropriate the codes are again
modified to generate the relevant function key code before being passed on.